Keep page feedback from readers who decline cookies - #480

This needs a privacy/consent review: the disclosure no longer matches where the data goes. For a reader who declined cookies, this sends the comment, page URL and title to script.google.com, and the request carries their IP and user agent. That's a different processor and different storage (a spreadsheet) than the consent banner covers. The widget's note (index.tsx:376) still says the comment is "sent to our analytics tool with this page's address", which is no longer accurate on this path.

Partly addressed, still open: this needs a privacy/consent sign-off.

The disclosure now matches the destination (7c8da0b, 5507dce): on the fallback path, the note says the comment, the vote and the page's address and title go to a Google Apps Script form that adds them to a spreadsheet, and that the request carries the browser's IP address and user agent. On the analytics path, the note is unchanged.

What code can't settle: a reader who declines the cookie banner is exactly who the fallback sends to. That's the point of this PR, so someone responsible for privacy and consent needs to confirm it's acceptable before this ships.

No build sets DOCS_FEEDBACK_ENDPOINT or DOCS_FEEDBACK_TOKEN. build-docs.yml (line 61) and docs-preview.yml run yarn build with no env block, so in production this is '', sendDirectFeedback returns false, and the fallback ships turned off. Please add the variables (as secrets or vars) to the deploy workflow, or this PR has no effect.

Still open: the variables don't reach production yet.

I added DOCS_FEEDBACK_ENDPOINT (repo variable) and DOCS_FEEDBACK_TOKEN (repo secret) to the build step of build-docs.yml, for main only, and previews never get them (docs-preview.yml, and docusaurus.config.ts forces both to empty when preview_build is set). But build-docs.yml only builds and tests; nothing in this repo deploys the live site. So the pipeline that builds production must set these two variables too, or the fallback stays off. Who owns that pipeline? Until it's configured, merging this changes nothing for readers.

Thanks, and sorry: my original comment pointed you at the wrong workflow. docs.scandit.com is built and published by generate-docusaurus-documentation-production in the data-capture-sdk GitLab project, on an hourly schedule. It clones main here and runs npm run build.

I opened a GitLab MR that passes the two variables to that job only: https://gitlab.scandit.com/mobile/data-capture-sdk/-/merge_requests/39858

• It maps DOCS_FEEDBACK_ENDPOINT_PROD and DOCS_FEEDBACK_TOKEN_PROD to the names docusaurus.config.ts reads. The staging job runs the same script, so it doesn't get them and can't post into the production sheet.
• A GitLab maintainer still has to create those two CI/CD variables. Ideally do that before this PR merges: the production job skips the build while the docs commit is unchanged, so variables added later only take effect with the next commit to main.
• The env: block in build-docs.yml doesn't affect production. Keeping it is fine, but the comment above it shouldn't suggest it's what turns the fallback on. Dropping it would also let you remove the GitHub repo variable and secret.

I'll leave this thread open until the GitLab side is configured.

Reopening this one. @eugenia-scandit, I think cd2d304 should be reverted. It doesn't match how the merged GitLab MR (https://gitlab.scandit.com/mobile/data-capture-sdk/-/merge_requests/39858) works.

The MR doesn't give the docs build the _PROD names. It reads them and passes them on under the plain names, in the production job only:

# generate-docusaurus-documentation-production
DOCS_FEEDBACK_ENDPOINT: $DOCS_FEEDBACK_ENDPOINT_PROD
DOCS_FEEDBACK_TOKEN: $DOCS_FEEDBACK_TOKEN_PROD

The _PROD names exist so the docs build never reads them directly. The staging job (generate-docusaurus-documentation-staging) runs the same build script. If docusaurus.config.ts reads DOCS_FEEDBACK_ENDPOINT_PROD and the variables are created at project level, staging gets them too, and staging.docs.scandit.com posts into the production sheet. The MR's mapping would also have nothing left to read it.

With the config back on DOCS_FEEDBACK_ENDPOINT / DOCS_FEEDBACK_TOKEN (and build-docs.yml the same), it works as intended. Only production sees the values, and they can be masked project variables.

Still to do before this is done:

• Revert cd2d304.
• Create DOCS_FEEDBACK_ENDPOINT_PROD (the Web App /exec URL) and DOCS_FEEDBACK_TOKEN_PROD as CI/CD variables in mobile/data-capture-sdk. Neither exists yet. You have the values; @moritzhartmeier can add them. Ideally do this before this PR merges: the production job only rebuilds when the docs commit changes.